K/KK/77K-6 


n /® — 1 — I 

I Vj^'onnoth  1../ Marvin  y 

— — * ^rai’iiaiii  • — Wi^'**-* 


Approved  for  public  reloaso;  distribution  unlimited. 


D D C 


' t 


,HJN  15^ 

iM 

12i 


u 1. 


GjyE5;/77S-6 


STRUCTURED  ANALYSIS  AND  DESIGN  OF  A 
SATELLITE  SIMULATOR 


THESI 


C 

kJ 


PreBentod  to  the  Faculty  of  the  School  of  Engineering 
of  the  Air  Force  Institute  of  Technology 
Air  Univercity 

In  Partial  Fulfillment  of  the 
RequlremontG  for  the  Degree  of 
Maetor  of  Science 


fUlS 

V c 

UNAf.-'tl  " :l 
JUilli  XUll’H 


t-  !>  : jii 


‘'I 
1 1 i 


Br 

lilSrilMiJlipfi  Ai'f  II  4,:|i 'll  j 

BIsl.  ,|, 


ft 


by 

Kenneth  L.  Marvin,  B.S.E.S. 
Captain  DSAF 

Graduate  Electrical  Engineering 
September  1977 


Approved  for  public  release;  distribution  unlimited 


Preface 


This  thesis  presents  an  effective  application  of  a structured 
aD,alysis  and  structured  design  methodology  to  a complex  satellite 
command  system.  The  methodology  used  combines  features  of  three 
different  design  techniques.  The  key  to  the  successful  develop- 
ment is  the  preliminary  aesign  which  gives  a complete  requirements 
definition  in  an  understandable  diagram  form.  A series  of  these 
diagrams  are  combined  to  form  an  activity  model  and  a data  model 
of  the  simulator  using  a top-dovm  design  strategy.  The  activity 
model  is  the  starting  point  of  the  design  refinement.  A first  cut 
structure  chart  is  drawn  directly  from  the  activity  model,  A data 
flow  graph  is  then  created  which  in  turn  is  converted  into  a re- 
fined structure  chart.  The  refined  structure  chart  is  the  primary 
vehicle  which  facilitates  the  programming  phase.  Even  though  the 
programming  has  not  been  done  in  this  thesis,  a structured  analy- 
sis and  design  has  been  performed  that  presents  a satellite  simu- 
lator that  is  modifiable,  underst.andable , and  free  of  implementa- 
tion constraints, 

I thank  iiy  thesis  advisor.  Captain  Peter  E,  Miller,  for  his 
professional  influence  and  guidance  throughout  this  project.  Thanks 
must  also  be  extended  to  Captain  J.  B.  Peterson  for  sharing  his 
expertise  with  me  in  this  endeavor,  A very  special  thanks  goes 
to  my  wife,  Maryanne,  and  to  our  children,  Kevin  and  Cindy,  with- 
out their  patience  and  love  this  effort  would  have  been  wasted, 

I cannot  close  without  thanking  God  whose  eternal  wisdom  has  pre- 
vailed throughout, 

Kenneth  L.  Marvin 
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Abetrac  t 


The  problem  addroesed  in  thie  thoGic  is  the  ^analysis  of  a 
complex  satellite  command  system  and  the  design  of  a software  sim- 
ulation of  that  system.  The  problem  is  solved  in  three  steps. 
First,  a written  requirements  definition  establishes  a sound  view- 
point and  purpose  on  which  the  analyst  can  base  his  design.  This 
requirements  definition  explains  why  the  simulator  is  to  be  cre- 
ated, how  it  is  to  be  constructed,  and  what  it  is  to  do.  Second, 

A top-down  strategy  called  "structured  analysis"  is  applied  to 
create  the  preliminary  design.  The  structured  analysis  is  pre- 
sented in  a blueprint-type  language  with  activity  and  data  models. 
The  models  represent  graphically  the  functions  performed  by  the 
simulator  and  the  information  upon  which  those  functions  act.  A 
final  design  refinement  is  performed  with  a structured  design  meth- 
odology called  "transform  analysis."  The  structure  charts  drawn 
during  the  transform  analysis  reveal  system  characteristics  which 
illustrate  design  quality.  The  activity  model  acts  as  a catalyst 
to  a successful  transition  from  a top-down  analysis  to  a structured 
design  which  can  be  evaluated.  The  resulting  simulator  design, 
with  minor  revisions,  satisfies  the  design  goals  established  for 
the  project.  The  metl,odology  used,  is  highly  recommended  for  the 
analysis  and  design  of  iiny  software  system. 


STRUCTURED  A^AIYSIS  AN’D  DESIGN  OF  A 


SATEILITE  SIMUIAT’OR 

I.  Introduction 

Objectives 

This  thesis  prescntvS  a "structured’’  developnent  of  the  require- 
ments and  the  design  needed  to  create  a software  simulation  of  an 
operational  satellite.  A good  development  technique  is  required 
to  maite  the  final  programming  easier  and  more  understandable.  The 
primary  objective  of  this  thesis  is  to  avoid  iill  of  the  negative 
effects  of  a premature  system  design  (Ref  To  meet  that  ob- 

jective, it  is  necessary  to  do  a complete  and  understandable  require- 
ments analysis  of  the  system  to  be  designed.  A requirements  anal- 
ysis is  the  first  stop  towards  the  design  of  a high  quality  system 
that  is  efficient  and  reliable. 

Any  quality  development  project,  be  it  hiirdwai'e  or  software, 
must  be  based  on  an  orderly,  controlled,  and  disciplined  methodol- 
ogy. (Ref  6:5).  While  searching  for  such  a methodology,  the  top- 
doim  design  phases  of  the  software  life-cycle  are  considered.  The 
first  two  steps  in  the  life-cycle  are  classified  as  "system  require- 
ments" and  "software  requirements"  (Ref  2:3-4).  A thorough  expla- 
nation of  the  system  and  the  functions  it  performs  must  be  present- 
ed. This  explanation  is  given  by  a Requirements  Definition  as  de- 
fined by  SofTech,  Inc.  (Ref  4:4).  The  Requirements  Definition  is 
the  first  portion  of  SofTech' s Structured  Analysis  and  Design  Tech- 
nique (SADT).  It  is  this  portion  of  the  SADT  that  is  used  in  the 
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requirements  analysis  cond  preliminary  design  of  the  satellite  sim- 
ulator, Requirements  Definition  deals  with  three  subjects:  context 
analysis,  design  constraints,  and  functional  specifications.  Those 
subjects  give  a definition  of  the  requirements  for  an  efficient 
and  long-range,  cost-effective  system.  The  context  analysis  explains 
why  the  system  should  be  created  and  why  certain  technical  and  op- 
erational capabilities  set  the  boundary  conditions  for  the  system. 
Design  constraints  explain  how  the  system  is  to  be  constructed. 

The  objective  here  is  not  to  specify  which  things  will  be  in  tlio 
system,  but  only  to  set  limits  for  selection  of  those  things  at 
a later  time.  The  functional  specifications  are  of  primary  inter- 
est, These  specifications  give  only  the  boundary  conditions  for 
requirements  taken  up  in  the  design  phase  (Ref  6:5-6). 

The  next  phase  in  the  software  life-cycle  is  the  preiimin.ai'y 
design.  The  objective  is  to  define  system  requirements  more  oxp*lic- 
itly  and  to  present  a functional  analysis  that  is  conceptually  com- 
plete, During  this  phase  in  the  development,  a design  is  produced 
that  malces  coding,  debugging,  £ind  modification  easier,  faster,  ai\d 
less  expensive  by  reducing  complexity  (Ref  9:115).  After  the  pre- 
liminary design,  a departure  is  made  from  the  SADT.  This  departure 
is  required  to  provide  a design  refinement  that  can  be  evaluated. 

A design  technique  called  "transform  anaJ.ysis"  is  performed  which 
has  characteristics  that  reveal  design  quality  (Ref  10:254-300). 

The  combination  of  the  preliminary  design  based  on  structured  anal- 
ysis and  the  design  refinement  based  on  transform  analysis  creates 
a satellite  simulator  design  that  is  modifiable,  understandable, 
and  free  of  implementation  constraints. 
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Tho  BponGor  of  thie  thoeie  is  the  /4OOO  Aorospnce  Applications 
Group  (SAC),  located  at  Offutt  Air  Force  Base,  Nebraska.  They  are 
responsible  for  command,  control,  and  analysis  of  tho  weather  sat- 
ellite (Block  5D) I which  is  to  be  simulated.  Operational  require- 
ments place  a limit  on  the  amount  of  software  development  that  can 
be  done  "in  house."  A need  exists  for  a simulator  that  Ciui  be  used 
as  a training  device  for  satellite  controllers  auid  as  mi  analysis 
aid  for  eatel.llte  data  analysts.  The  purpose  of  this  thesis  Is 
to  provide  a design  of  such  a simulator. 

Scope 

The  initial  investigation  of  the  satellite  system  shows  that 
a simulation  of  all  the  satellite  functions  is  beyond  the  scope 
of  this  thesis  (Ref  1),  However,  a simulation  of  tho  spacecraft 
command  "uplink"  and  command  verification  (CV)  "downlink"  is  of 
primeiry  importance,  A simulator  is  required  that  ’will  accept  space- 
craft commands  in  a realistic  format,  simu''ate  performance  of  the 
proper  functions  in  response  to  those  commands,  and  maintain  rec- 
ords of  spacecraft  status  (l.o,  telemetry  point  values,  transmit- 
ters on  or  off,  etc.),  which  can  be  modified  at  user  request.  In 
addition,  the  simulator  should  be  designed  in  a modular  fashion 
to  ensure  the  modifiability,  maintainability,  and  understaiidabllity . 
The  structured  analysis  and  design  techniques  used  in  this  devel- 
opment effort  present  a modular  system  that  is  function^llly  inde- 
pendent* This  independence  m^lkeB  it  easy  to  add  or  delete  modules 
to  further  enhance  tho  realistic  nature  of  the  simulvatlon  at  a later 
time.  No  attempt  is  made  to  do  the  actual  programming  required 
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to  implement  the  simulator.  However,  the  structured  techniques 
used  to  perform  the  analysis  and  design  will  facilitate  the  final 
programming  phase. 

Plan  of  Development 

Chapter  II  is  a presentation  of  the  Requirements  Definition 
with  emphasis  placed  on  the  functional  specifications.  Chapter 
III  presents  a Preliminary  Design  of  the  simulator  in  the  form  of 
activity  and  data  models.  The  approach  used  in  both  of  these  chap- 
ters is  based  on  the  technique  prepared  by  SofTech,  Inc.  called 
"structured  an.alysis.''  Chapter  IV  presents  a refjjiement  of  the 
preliminary  design,  which  is  illustrated  with  structure  charts  and 
data  flow  graphs  (bubble  charts).  These  charts  and  graphs  are 
used  to  do  the  transform  analysis.  Chapter  V contains  a summary 
of  results  obtained  in  this  development  as  well  as  conclusions  and 
recommendations. 
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II.  RocjUlreraentB  Definition 


Introduction 

The  phase  of  the  software  life-cycle  most  often  abused,  or 
neglected.  Is  the  Requirements  Definition.  The  Requirements  Def- 
inition presented  In  this  chapter  is  in  a written  form  to  show  a 
dirtinction  between  It  and  the  illustrative  functional  design  pre- 
sented in  Chapter  III.  This  order  of  development  allows  the  ana- 
lyst to  establish  a sound  viewpoint  and  purpose  on  which  to  base 
his  first  phase  of  design.  The  lack  of  a Requirements  Definition 
usually  results  in  rising  costs,  missed  schedules,  waste  and  dupli- 
cation (Ref  4:2).  In  addition,  the  elimination  of  this  important 
step  results  in  the  absence  of  a useful  documentation  package. 

This  creates  the  most  common  problem  with  large  systems  in  the  Air 
Force:  a lack  of  understanding  by  the  engineer  who  takes  over  the 
project.  He  typically  must  spend  an  inordinate  amount  of  tine  nearly 
’’redeveloping"  the  system  to  bring  his  level  of  understanding  to 
a point  where  he  can  be  productive. 

Included  in  this  chapter  is  (1)  a context  analysis,  which 
tells  why  the  simulator  is  to  be  created,  (2)  a set  of  design  con- 
straints, to  tell  how  the  simulator  is  to  be  constructed,  and  (3) 
a set  of  functional  specifications  that  describe  what  the  system 
is  to  do. 

Context  Analysis 

To  better  understand  why  a satellite  simulator  is  to  be  cre- 
ated, an  explanation  of  the  environment  (context)  in  which  it  is 
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to  be  used  ie  needed.  This  explanation  in  given  in  the  context 
aneilyeie  which  follows. 

The  ifOOO  Aerospace  Applications  Group  (SAC)  is  responsible 
for  the  command  and  control  of  weather  satellites  in  support  of 
Global  Weather  Central  at  Offutt  Air  Force  Base,  Nebraska,  It  is 
also  responsible  for  monitoring  spacecraft  telemetry  and  data  to 
aid  in  detection  of  any  anomalies  that  may  have  occurred  during 
its  orbit.  Over  the  yeai'S  these  satellites  have  increased  in  com- 
plexity and  produce  more  data  for  analysis  nurposes.  This  has  in- 
creased the  need  for  a good,  easy  to  use  simulator  to  aid  in  anom- 
aly analysis  and  to  function  as  a training  device  for  new  system 
controllers. 

To  perform  as  an  analysis  tool,  the  simulator  must  display 
current  telemetry  point  values  upon  request.  It  must  also  provide 
the  analyst  with  current  status  information  about  transmitters, 
central  processing  units,  and  sensors  on  the  spacecraft.  This  in- 
formation must  be  provided  after  each  spacecraft  command  is/given 

/ 

to  the  simulator  and  upon  request  from  the  user. 

The  simulator  must  accept  its  input  in  the  same  format  that 
is  transmitted  to  the  satellite.  This  formatting  i.s  currently  done 
by  an  existing  hardware  device  known  as  the  5D  Interface  (5DI), 
Commands  will  be  input  through  the  5M  to  the  simulator.  In  addi- 
tion to  the  outputs  mentioned  above,  the  simulator  should  provide 
the  proper  command  verification  words  and  an  explanatory  message. 

Design  Constraints 

This  section  is  a summary  of  the  conditions  specifying  how 
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the  simulator  is  to  be  constructed.  No  attempt  is  made  to  specify 
input  or  output  devices.  Those  details  should  be  considered  at  a 
later  stage  in  the  design  (Ref 

There  are  four  fundamental  goals  which  should  be  considered 
by  the  software  engineer  when  he  begins  his  development  process. 
They  are  (1)  modifiability,  (2)  efficiency,  (3)  reliability,  and 
(4)  understandability  (Ref  5:89).  These  are  the  constraints  con- 
sidered in  the  process  of  selecting  the  analysis  and  design  tech- 
niques used.  The  techniques  selected  are  SofTech's  structured  a- 
nalysis  for  the  preliminary  design  and  a structured  design  method 
for  the  design  refinement. 

Functional  Specifications 

Functional  specifications  are  imposed  on  the  functional  ar- 
chitecture ot  the  system.  They  differ  from  system  architecture 
specifications  because  they  outline  the  purposes  of  the  system  in- 
stead of  giving  the  languages,  transmission  links,  and  record  for- 
mats that  arc  in  the  system  (Ref  4:8).  The  following  functional 
specifications  are  a first  step  towards  the  creation  of  the  func- 
tional architecture.  The  next  chapter  presents  the  functional  ar- 
chitecture as  the  preliminary  design  of  the  simulator. 

There  are  four  main  functions  that  should  be  performed  by 
the  simulator.  It  should  (1)  process  the  input  word,  (2)  update 
the  vehicle  (simulator)  status  in  response  to  the  input  word,  (3) 
create  the  appropriate  command  verification  words,  and  (4)  create 
an  output  message  informing  the  user  what  action  has  been  taken. 

A brief  description  of  each  of  those  functions  follows. 
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Process  Input  Word.  A satellite  simulator  input  should  be 


classified  as  a spacecraft  uplink  command  or  a user  command,  A 
user  command  modifies  the  current  vehicle  status  data,  i.e,  change 
a telemetry  point  value,  add  or  delete  a status  table,  etc.  A space 
craft  uplink  command  must  be  properly  formatted  before  it  can  be 
executed.  The  formatted  command  simulates  satellite  functions  by 
updating  status  data  and  creating  the  appropriate  command  verifi- 
cation message.  The  formatted  command  must  first  be  checked  for 
parity  and  wordlength.  If  an  error  is  detected,  it  is  saved  and 
used  later  by  the  simulator  to  generate  the  proper  command  verifi- 
cation words  and  output  messages. 

After  the  initial  format  checks  are  made,  the  spacecraft  com- 
mand type  must  bo  determined.  This  determination  will  influence 
the  kind  of  sequence  checks  that  need  to  be  performed.  Some  space- 
craft commands  require  a series  of  sub-commands  in  a specified  order 
while  others  require  a specific  time  interval  between  them  before 
they  can  be  executed. 

The  processing  just  described  will  produce  a user  command 
in  the  form  of  some  type  of  status  modification  word,  a spacecraft 
command  that  will  contain  some  errors  (invalid  command),  or  a space- 
craft command  that  is  error- free  (valid  command).  One  of  these 
inputs  will  be  passed  to  the  remaining  functional  activities  for 
appropriate  processing, 

Jpdate  Vehicle  Status,  Only  a user  command  or  a valid  space- 
craft command  effects  the  current  status  information.  An  invalid 
command  is  only  acknowledged  by  the  command  verification  function. 
When  the  required  modification  is  determined,  an  update  request 
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is  issued  and  the  necessary  update  function  is  performed.  The  new 
status  information  is  then  given  to  the  user. 

Create  Command  Verification  Words.  Previously  detected  er- 
rors should  be  listed  and  used  to  determine  the  applicable  command 
verification  (CV)  codes.  These  CV  codes  are  transmitted  via  the 
downlink  from  the  spacecraft  after  a command  has  been  received. 

To  make  the  simulator  a more  valuable  analysis/ training  device, 
an  explanatory  message  should  be  output  with  the  CV  code.  There 
are  also  verification  codes  associated  with  valid  spacecraft  com- 
mands which  should  be  handled  in  the  same  manner  as  the  erroneous 
command  codes. 

Create  Output  Messages.  The  CV  words  are  now  translated  and 
a meaningful  output  message  is  produced.  Any  status  modifications 
are  noted  with  a specific  update  message.  The  messages  are  assem- 
bled and  a complete  and  easily  understood  output  text  is  produced. 

Summary 

This  chapter  presents  a context  analysis  of  the  problem,  de- 
sign constraints  for  its  solution,  and  functional  specifications. 

The  context  analysis  forms  a perspective  from  which  to  view  the 
overall  problem.  An  effort  is  made  not  to  let  the  context  analy- 
sis be  functional  specifications,  however,  the  context  analysis 
and  functional  specifications  are  closely  related  and  in  some  cases 
it  is  difficult  to  separate  the  two.  The  design  constraints  are 
imposed  by  the  desired  design  goals.  Analysis  and  design  techniques 
are  selected  that  should  make  the  design  meet  those  goals.  The 
functional  specifications  are  given  in  lodular  sections  which  are 
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the  four  baeic  unite  needed  for  construction  of  the  next  lovol  of 


design.  This  construction  consists  of  the  SADT  activity  and  data 
models  presented  in  the  next  chapter. 
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Ill,  Preliminary  PctUtrn 


Introduc  tlon 

'I'he  activity  and  data  modelc  procented  In  this  chapter  rop- 
reson  •.  the  reDuite  of  many  attemjte  to  llluctrate  the  concoptuid 
ideas  conveyed  by  the  functional  Gpeclfications.  Those  models, 
organised  as  a sequence  of  diiigrams  with  supporting  text,  form  the 
preliminary  design. 

The  activity  model  is  presented  first,  followed  by  the  data 
model.  These  models  graphically  represent  the  functions  performed 
by  the  system  and  the  data  upon  which  the  functions  act.  Each  nodoi 
contains  ooth  data  und  activities  with  complimentary  emphases. 

The  combination  loads  to  "a  much  richer  understanding  of  the  sub- 
ject than  is  afforded  by  a single  model"  (Ref  7:  Chap,  2,  p,  3). 

Each  level  of  modules  is  a more  detailed  decomposition  of  the  level 
above.  This  structured  decomposition  is  tlie  substance  of  top-down 
design.  The  following  is  a brief  e:cpl;ination  of  the  diagram  syn- 
tax to  aid  the  r'  lor  in  understanding  the  models,  A more  detailed 
discussion  can  be  found  in  reference 

Diagram  Syntax 

Structured  Analysis  diagrams  are  composed  of  boxes  and  iUTows 
which  are  a vehicle  for  clearly  expressing  activity  and  data  mod- 
ules (Ref  7:  Chap.  3f  P»  0.  Figure  1 illustrates  examples  of  the 
activity  and  data  modules.  The  "mechanism"  arrows  are  shown  for 
completeness  but  are  not  used  at  this  stage  of  the  design  since 
they  are  intended  to  represent  the  functions  or  hardware  needed 
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to  realize  the  module.  The  "multiple  branch"  (exclusive  OR)  is 
used  to  indicate  multiple,  but  not  simultaneous  outputs.  The 
"multiple  Join"  indicates  multiple,  but  not  simultaneous  Inputs. 
Both  conventions  are  shown  in  Figure  2. 

In  general,  data  and  activity  modules  are  decomposed  into 
more  detailed  data  and  activity  modules.  Each  modulo  thav  is  de- 
composed is  referred  to  as  a "parent"  modulo  and  modules  that  re- 
sult from  the  docomposltlon  are  the  "children."  To  relate  the 
arrows  of  the  children  to  those  of  the  parent,  an  "ICOM"  code  is 


INPUT 

(data) 


CONTROL 

CONTROL 

(da. 

:a) 

(activity) 

ACTIVITY 

^OUTPUT  INPUT  ^ 

DATA 

^UTPUT 

TITLE 

(data)  (activity) 

TITLE 



(activity) 

MECHANISM 

(processor) 


MECHANISM 
( store) 


Figure  1.  Module/lnterfaces  Arrow  Conventions 


is  used.  The  acronym  is  derived  from  the  arrow  nsoaos:  input,  con- 
.rol,  output,  and  mechanism.  Each  arrow  at  the  paront/chlld  bound- 
ary is  uniquely  labeled  with  the  letter  I,  C,  0,  or  M with  prefix 
and  suffix  numbers.  The  prefix  number  refers  to  the  module  within 
the  child  and  the  suffix  number  refers  to  the  top-down  or  left- 
right  order  of  the  arrow  on  a module.  The  boundary  is  the  outer 
border  of  the  activity  or  data  diagram.  Each  diagram  is  called 
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two-way  branch 


three-way  Join 


I 

!■ 
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} 

i 
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] 

I 
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(' 
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I 

:| 

. 71 


Figure  2.  OR  Branch  and  Join  Structures 

a "node," 

Reading  Sequence 

The  following  is  a suggested  reading  sequence,  looking  at 
each  module  in  top-down  order: 

1,  Scan  the  boxes  to  get  a first  impression. 

2,  Rethink  the  message  of  the  parent  module.  Observe  the 
boundary  arrows, 

3,  Refer  back  to  the  current  module,  checking  arrow  attach- 
ments between  it  and  the  parent, 

if.  Consider  internal  ai'rows.  Consider  boxes  from  top  to 
bottom  and  left  to  right, 

5*  Read  the  text. 
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Activity  Ho del 


Before  reading  the  activity  diagrams,  it  is  recommended  that 
the  "node  index"  given  below  be  scanned.  This  index  serves  as  a 
table  of  contents,  and  gives  an  overview  of  the  decomposition  struc- 
ture. 


Node 

Title 

Page 

A-0 

Simulate  Spacecraft 

15 

AO 

Simulate  Spacecraft 

17 

A1 

Process  Input  V/ord 

19 

A1 1 

Determine  Type  of  Input  Word 

21 

A12 

Format  Spacecraft  Command 

23 

A13 

perform  General  Validity  Checks 

25 

A14 

Determine  Type  of  Command 

27 

A15 

Perform  Command  Validity  Checks 

29 

A2 

Update  Vehicle  Status 

31 

A21 

Determine  Type  of  Modification  Required 

33 

A22 

Perform  Update 

35 

A3 

Generate  CV  Words 

37 

A31 

List  Types  of  Format  Errors 

39 

A32 

List  Types  of  Sequence  Errors 

41 

A33 

Determine  Proper  Vehicle  Messages 

43 

A4 

Create  Output  Messages 

45 

14 


Parity/Wordler.gth 
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Figure  3«  Slaulate  Spacecraf 


A-0  Text;  An  input  word  (II)  i£  received  by  the  simulator*  That 
word  is  either  a user  command  or  an  uplink  spacecraft  command,  but 
not  both  at  once.  The  activity  performed  ("SIinJTATS  SPACECRAFT") 
is  constrained  by  the  type  of  input  word  (Cl),  or  by  the  parity, 
wordlength  (C2)  and  type  (C3) , if  the  input  is  a spacecraft  command. 
The  final  product  of  the  activity  is  a complete  and  understandable 
message  to  the  user  (01)  for  problem  analysis  or  spacecraft  inter- 
rogation. 
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AO  Text;  An  input  word  (II)  is  received  by  Process  Input  Word  (1). 
That  word  is  either  a user  command  to  modify  vehicle  (simulator) 
status  or  an  uplink  spacecraft  command.  If  it  is  a user  command, 
it  is  passed  as  a statue  modification  (101)  to  control  the  Update 
Vehicle  Sta>,UB  (2)  and  Create  Output  Messages  (4)  activities.  If 
the  input  word  is  a spacecraft  command,  two  constraints  determine 
the  type  of  output.  These  constraints  are  parity/'wordlength  (C2) 
errors  and  command  typo  (C3)«  If  there  are  no  format  (parity/ word- 
length)  errors,  a valid  command  (103)  ic<  used  to  control  the  other 
activities.  Another  possibility  is  an  invalid  command  (102)  which 
results  from  a parity/wordlength  error.  Update  Vehicle  Status  (2) 
uses  the  status  modification,  the  valid  command,  or  the  invalid  com- 
mand to  determine  the  required  vehicle  status  updates.  The  current 
status  (20'i)  is  used  as  part  of  an  output  message  (401).  A valid 
command  is  acknowledged  by  a Command  Verification  (CV)  Word  (301). 
Generate  Commiind  Verification  Words  (3)  produces  these  CV  words 
and  they  are  used  by  Create  Output  Messages  (4),  along  with  the 
constraints  shown,  to  produce  an  output  message  responsive  to  th^ 
particular  input  word  that  is  being  processed. 
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Figure  5«  Process  Input  7/ord 


A1  Text:  Dotermlno  Type  of  Input  Word  (1)  is  pritaari].y  concerned 
with  whether  on  input  is  in  the  format  nececsary  to  simulate  an 
uplink  spacecraft  commajid  (102),  or  in  a user  command  format  to 
bo  processed  as  a status  modification  (101).  The  spacecraft  command 
is  first  formatted  properly  for  use  by  the  simulator.  The  formatted 
command  (201)  is  passed  to  the  remaining  activities  for  processing. 
After  the  command  is  chocked  for  parity/wordlength  (021  it  is  de- 
coded to  determine  the  command  typo  (03  . Finally,  it  is  checked 
for  proper  sequencing.  Determine  Typo  of  Oommand  (4)  performs  its 
function  on  a command  oven  if  it  contains  a format  error.  Perform 
Oommand  Validity  Ohocks  (3)  outputs  an  invalid  command  (501)  or  a 
valid  command  502)  to  bo  used  by  the  next  activity. 
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^pe  of 

Word 
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Deteraine  Type  of  Input  Word 


All  Text;  If  tho  Input  Word  (H)  is  a user  modification,  Read  Sta- 


tus Modification  Word  (1)  outputs  a status  modification  request 
(101)  which  controls  Perform  Status  Modification  (2),  Upon  receipt 
of  the  particular  request,  a status  modification  (201)  is  outputc 

Upon  receipt  of  a word  in  the  uplink  format,  activity  (3)  reads 
the  tpacecraft  uplink  word  and  outputs  the  spacecraft  command  (502) 
for  use  by  the  next  activity. 
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Spacecraft 


Figure  7»  Format  Spacecraft  Command 


Al^  Text:  After  it  is  determined  that  the  input  word  (II)  is  a 
spacecraft  comr.and  (Cl),  the  first  16  bits  of  the  word  are  read 
in  activity  (1)  and  the  spacecraft  data  (101)  is  output.  The  re- 
ma^ning  nine  bits  oX  the  word  are  read  in  activity  (2)  and  the 
spacecraft  address  (201)  information  is  passed.  Both  of  these  out 
puts  are  stored  by  (3)  and  they  are  the  formatted  command  (301). 


2, 


Ity/Wordlength 


Figure  8.  Perform  General  VeJ-idlty  Checks 


A13  Text:  The  formatted  command  (II)  is  input  to  both  activity 
boxes  (1)  and  (2)  for  a v/ordlength  check  and  a parity  check. 
There  are  various  error  codes  that  are  associated  with  individ- 
ual commands.  After  the  error  checks  have  been  made,  any  errors 
that  have  been  found  are  used  to  determine  the  codes,  that  apply 
to  the  particular  command  and  error  (5)» 
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A14  Text:  The  command  type  (C2)  must  be  determined  for  all  com- 


mands, If  format  errors  (Cl)  exist,  they  are  passed  as  indica- 
tions of  an  erroneous  command  (101),  or  an  error-free  command  (102). 

The  CPU  Interrupt  Code  (CIC)  is  road  (2)  from  the  formatted 
command  (II).  This  code  will  relate  to  a certain  type  of  command. 
The  command  words  (01)  that  are  output  are  either  invalid  or  val- 
id, doponding  on  ahother  a format  error  has  or  has  not  been  de- 
tected, These  determinations  must  bo  made  before  the  particular 
command  can  bo  executed. 
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Command 


Figure  ]0«  Perform  Command  Validity  Checks 


A13  Text:  Each  formatted  command  (11)  that  has  survived  the  Gen- 
eral Validity  Checks  without  error  must  go  througli  a series  of 
Command  Validity  Cliecks  as  conf rolled  by  the  specific  command 
(Cl)  that  is  input  to  the  simulator.  First  it  is  determined  if 
a CPU  address  error  exists  (1).  If  such  an  error  exists,  thiat 
error  is  saved  for  future  use.  If  there  is  no  CPU  addresi  error 
(101),  the  command  sequence  is  checked  in  activity  (/I),  and  any 
sequencing  errors  (POl)  that  may  arise  are  saved  in  a like  manner 
as  the  address  error.  Check  Command  Timing  (5)  works  in  a simu- 
lar  manner  as  (2)  and  is  added  for  completeness,  A timing  error 
will  result  in  the  same  error  code  as  a sequence  error.  If  this 
modulo  is  implemented,  the  sequence  error  and  the  timing  error 
should  be  assigned  a different  error  message  so  the  user  can  dis- 
tinguish between  the  two  when  they  occur. 
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Status  Cl  C2  Valid 

Modification  I I Coaaand 


AP.  Text:  A tUnLiu:  inoiiificj  Lion  (Cl")  ronnlLn  from  a unor  comrjniui 


input.  Dotorinl.no  Typo  of  Modification  Ihiouirod  (1)  nnalyr.oo  it, 
or  n valid  C(  mmand  (CP)  that  may  liavo  boon  traiir.ml I Lod , to  r.oo 
what  kind  of  updato  roquont  (101)  to  nocooG.iry.  After  that  (.0- 
tormination  hafj  boon  made,  I orform  llptiato  (P)  it;  activatod  tnd 
the  otatuG  information  io  pacr.od  tv>  tlio  output  modulon. 
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A21  Text:  Igguo  Spoclfic  Change  Roquost  (1)  utiiizoG  the  Gtatu 


modification  (Cl)  that  ic  being  performed  ac  a constraint  wliich 
dotormincG  whether  there  chould  be  a requeet  made  or  !\ot.  'Vhon 
a valid  command  has  been  trancmit t ed , the  command  data  ic  read 
from  it  by  (2)  and  the  appropriate  change  rocinest  ic  pauGcd  to 
(3),  With  either  requect,  (301)  or  (3C2),  an  the  determining 
factor,  a particular  update  request  (01)  is  then  issued. 
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update 


Figiire  13*  Perforir  Update 


A22  Text:  An  update  request  that  is  issued  as  a result  of  either 


a user  command  or  a valid  spacecraft  command,  can  require  telem- 
etry value  changes  to  be  made  (1),  status  nessage  changes  to  be 
made  (2),  or  both.  The  changes  that  are  made  are  assembled  to 
form  a list  of  current  status  data  (01)  to  be  used  to  create  an 
informative  output  as  a final  product  of  the  simulator. 
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Figure  t4«  Generate  CV  Words 


A3  Text:  An  invalid  coinciand  (Cl)  can  be  the  roau.'' t of  a parity 
error,  a wordlength  error,  or  some  type  of  command  sequencing 
error,  Ijst  Types  of  Format  ;>rors  (1)  extracts  errors  listed 
as  a result  of  the  general  validity  checks  performed  earlier. 

The  specific  format  errors  (101)  '.vhich  are  output  are  used 
to  aid  in  determination  of  the  proper  CV  words  (01)  to  be  pass- 
ed.  The  other  constraining  factors  are  the  specific  sequence 
errors  (301),  and  the  valid  command  (C3)  when  there  are  no  errors. 
Almost  all  of  the  spacecraft  commands  require  a command  verifi- 
cation (CV)  message,  whether  they  be  valid  or  invalid. 
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Invalid- 


Figure  15,  List  Types  of  Format  Errors 


A31  Text:  A parity  error  (101)  and/or  a wordlength  error  (201) 
is  listed  by  Assemble  Format  Errors  (5),  The  specific  format 
errors  (01)  that  are  ouput  are  used  to  create  the  proper  commaad 
verification  words  that  will  be  placed  In  the  simulated  dov/nllnk. 
This  node  presents  a decomposition  that  Is  almost  down  to 
the  coding  level.  Even  though  a small  amount  of  new  Information 
Is  Introduced,  It  Is  Included  to  enhance  the  clarity  of  the  par- 
ent node  (A5)» 
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Invalid 

Command 


Figure  16.  List  Tjpee  of  Sequence  Errors 


I 

1 


A3^  Text;  An  invalid  commadn  (Cl)  is  generated  due  to  a command 
sequencing  problem.  List  Memory  load  Errors  (1)  is  activated  if 
the  invalid  command  is  an  erroneous  memory  load  command.  A distinc- 
tion is  made  between  secure  commands  and  non-secure  commands  by 
activity  blocks  (2)  and  (3).  These  two  types  of  commands  generate 
their  own  set  of  command  verification  (CV)  codes  as  a result  of 
errors.  The  various  sequencing  errors  that  occur  during  a command 
process  are  assembled  in  (4)  and  the  specific  sequence  errors  (401) 
are  used  to  determine  the  proper  vehicle  message  codes  required  to 
generate  the  CV  words. 


UZ 


Specific  Specific  Valid 

Sequence  ^Format  /fconaand 


A.3.3  Text:  The  epecific  errors,  (Cl)  and  (C2)  , that  are  generated 
by  an  invalid  command,  are  used  to  control  the  generation  of  the 
applicable  error  codes  in  activities  (1)  and  (2),  If  a valid  com- 
mand (C3)  is  processed.  Generate  Specific  Command  Code  (3)  is  acti- 
vated to  provide  the  required  code  for  Generate  Command  Verifica- 
tion Words  (4).  All  of  the  codes  generated  contribute  to  the  crea- 
tion of  the  appropriate  CV  words  (401). 
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Figure  18.  Create  Output  MsBsagee 


A4  Text:  CV  words  (Tl)  are  Injiut  to  Translate  CV  Words  (1)  in 
a 16  bit  hoxidocimal  code.  The  words  are  translated,  and  the 
CV  mosoago  (101)  that  results  is  dotorminfd  by  the  currct t sta- 
tus (Cl),  and  the  valid  conraand  that  may  bo  present  (C3).  The 
status  modification  (C2)  inputs  to  1 roduce  Status  Change  listing 
(2)  and,  under  control  of  the  current  status,  a list  of  status 
changes  (201)  is  produced.  These  status  changes,  combined  with 
the  CV  message,  aid  in  producing  a meaningful  output  message  (01), 
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Data  Model 


Again,  as  with  the  activity  model,  it  is  recommended  that 
the  follov/ing  "node  index"  be  scanned  for  an  overview  of  the  d 
composition. 


Node 

Title 

Pag' 

D-0 

Simulator  Data 

48 

DO 

Simulator  Data 

30 

D1 

Input  Words 

52 

D1 1 

Spacecraft  Uplink  Word 

54 

D12 

Format  Errors 

56 

D13 

Status  Modification  Word 

58 

D14 

Formatted  Spacecraft  Command 

60 

D15 

Sequence  Errors 

62 

D2 

Current  Status  Data 

64 

D3 

Vehicle  Message  Data 

6b 

D4 

Output  Messages 

68 

47 


Deteralne  Typ*  of 
Error 


Elgure  19.  Simulate  Data 
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i 
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D-O  Text:  The  Input  activity  that  creates  or  modifies  the  Simulator 
Data  is  the  loading  of  the  input  word  (II).  What  is  done  as  a result 
of  the  input  word  is  constrained  by  the  determination  of  the  type 
of  input  word  loaded  (Cl),  the  type  of  error  (parity,  wordlength, 
or  sequence)  that  exists  (C2),  and  the  type  of  spacecraft  command 
that  is  transmitted  (C3)*  Any  input  that  is  loaded  results  in  the 


1 

printing  of  an  output  message  (01)  for  user  information.  ^ 


DO  Text:  An  Input  v/ord  is  loaded  (II)  which  1b  either  in  the 
form  of  a user  command  or  a cpacecraft  command.  The  Input  'Vorda 

(1)  that  are  created  are  then  used  by  one  of  three  possible  act- 
ivities, The  activity  that  uses  tl.e  Input  Word  is  constrained 
by  the  type  of  input  word  (Cl),  type  of  error  (C2)  that  may  e/- 
iot,  and  type  of  command  (C3)  that  ^lay  be  present. 

If  the  input  word  is  a user  command,  seme  type  of  status 
modification  or  vehicle  Information  update  wllj.  be  performed  (101). 
This  results  in  either  the  creation  of  some  Current  Status  Data 

(2) ,  or  a cliange  to  some  data  that  already  exists.  If  a space- 
craft command  is  input,  either  an  invalid  or  a valid  command  will 
affect  the  Current  Status  Data, 

The  valid  or  invalid  comm.and  process  determines  what  type 
of  veliicle  message  will  be  delivered  (301),  The  Vehicle  Message 
Data  (3)  is  shown  without  an  input  process  to  create  it.  This 
data  will  have  been  created  as  an  external  function  and  will  re- 
side in  the  simulator  for  access.  The  data  consists  of  command 
verification  and  error  codes  that  will  never  bo  altered  as  a 
function  of  the  simulator. 

The  status  changes  and  vehicle  messages  created  during  the 
command  process  are  assembled  as  Output  Messages  (4)  and  used  to 
print  output  messages  (01), 
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D1  Text;  If  tfte  input  word  (Tl)  is  a spacecraft  command  the  Space- 
craft Uplink  Word  (1)  is  created.  If  it  is  a user  command  a Status 
Modification  Word  (3)  is  created.  The  Status  Modification  Word 
is  used  to  perform  the  particular  status  modification  (501).  The 
Spacecraft  Uplink  Word  (1)  is  delivered  in  the  required  format  to 
create  a Formatted  Spacecraft  Command  (k)  and  Format  Errors  (2)  if 
they  exist.  The  Formatted  Spacecraft  Command  is  used  to  process 
the  invalid  command  (402)  or  it  is  delivered  as  a specific  command 
which  generates  Sequence  Errors  (5)*  Sequence  Errors  are  fed  back 
to  the  Formatted  Spacecraft  Command  (4)  and  used  to  process  the 
invalid  command. 
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Determine  Typ 
Input  Word 


Figure  22.9.  Spacecraft  Opllnk  Wcrde 


Dll  Text:  An  input  word  will  either  create  an  Uplink  Data  Word 
(1)  or  an  Uplink  Command  Word  (2).  Whichever  of  the  two  is  cre^ 
ated,  it  must  be  placed  in  the  proper  format  and  wordlength  to 
be  used  by  the  simulator.  After  the  Formatted  Commands  (3)  are 
created  they  are  delivered  for  further  processing  (01), 
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D12  Text:  When  processing  the  formatted  command  (II),  parity  and 
wordlongth  are  checked.  The  occurrence  of  eithfr  or  both  types 
of  errors  results  in  the  creation  of  Parity  (’)  and/or  Wordlength 
Krrors(2).  These  errors  are  then  used  to  create  the  Error  Data  (3). 
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D1^  Text;  After  it  has  been  deternined  by  (Cl)  that  the  input 
word  (II)  is  a user  command,  a Status  Modification  Request  (1) 
is  created.  This  request  is  then  processed  to  determine  the  par 
ticular  modification  required,  and  the  Modification  Information 
(2)  is  created  to  be  used  to  perform  the  modification  (01). 

It  should  be  noted  at  this  time  that  much  of  the  software 
required  to  perform  the  modifications  or  updates  to  the  simula- 
tor maji’  already  exist.  The  node  is  included  as  a reminder  that 
the  function  must  be  incorporated  in  the  simulation. 
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* 


Figure  25.  Fcrnatted  Spacecraft  Comisand 


D14  Text:  The  formatted  command  (II)  is  made  up  of  an  Address 


Word  (1)  and  a Data  Word  (2).  The  specific  content  of  these 
words  in  determined  by  Cl,  C2,  and  C3.  Many  different  things 
could  bo  the  cause  of  a particular  command  to  be  complimented. 

The  complimenting  is  dependent  upon  the  typo  of  command  word  pre- 
sent, and  on  the  existance  of  some  kind  of  error  in  that  command. 

It  is  also  dependent  upon  any  combination  of  the  two  clrcumstancos. 
The  same  constraints  apply  to  the  complimenting  of  the  Data  Word 
(2).  The  Complimented  Command  (3)  created  by  both  the  address 
word  and  the  data  word  is  used  to  further  process  the  invalid 
command  (30n.  By  knowing  a priori  which  commands  are  to  be  com- 
plimented and  which  commands  are  not  to  be  complimented,  a means 
of  detecting  commanding  errors  is  provided.  The  Specific  Command 
(4)  is  made  up  of  a good  address  word  and  a good  data  word.  It 
must  be  processed  (401)  to  determine  if  any  sequence  errors  exist. 
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D15  Text:  After  a command  is  found  to  have  no  parj  ty  or  wordleugih 


errors,  it  must  be  checked  for  proper  sequencing.  If  a sequence 
problem  is  detected,  either  a Memory  Load  Eri-or  (1),  a Secure  Com- 
mand Error  (2),  or  a Command  Sequence  Error  (3)  is  produced,  lAlien 
these  errors  are  created,  they  are  delivered  (301)  back  to  the  pre- 
vious node  (D14)  for  further  processing.  When  a command  is  received 
that  has  no  sequence  problem,  an  Error-Free  Command  (4)  is  created 
and  used  to  process  the  valid  command  (402), 


Perform  Status 
Modification 


(\i 

o 


0) 

o 
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Figure  27»  Ciirrant  Status  Data 


D2  Text:  Telemetry  Point  Values  (1)  are  the  main  source  of  sta- 


tus information.  A valid  command  (12)  must  be  processed  to  de- 
termine which  telemetry  indications  are  affected  by  its  execution. 
Once  the  telemetry  changes  are  performed  (101),  they  are  used 
in  the  update  of  the  Vehicle  Status  listings  (2).  The  status 
changes  (201)  are  then  used  to  aid  in  compilation  of  the  output 
messages.  Performance  of  status  modifications  (11)  requires  the 
same  data  processes  as  above. 
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Figiire  28.  Vehicle  Measago  Data 


D3  Text:  The  processing  of  a valid  or  an  invalid  conrr.and  causes 
the  delivery  of  a command  verification  (CV)  message  (101).  These 
messages  arc  derived  from  a file  o f CV  codes  that  are  available 
for  access  during  simulator  use.  The  invalid  command  also  ac- 
cesses error  codes  that  are  on  file  for  creation  of  proper  Error 
Messages  (2).  These  vehicle  messages  are  passed  on  be  assembled 
into  a me£mingful  output  message. 


Output  Messages 


D4  Text:  Status  Changes  (1)  and  Vehicle  Messages  (2:)  are  created 
as  a result  of  spacecraft  command  or  user  command  processing.  A 
Message  List  (3)  is  created  which  is  comprised  of  all  the  user  or 
vehicle  generated  changes  that  have  occurred  as  a result  of  a com- 
meind.  This  Message  List  is  printed  (01)  for  use  by  the  system  op- 
erator. 


ii 
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Summary 

After  a brief  introduction  and  explanation  of  some  diagram 
syntax,  this  chapter  presents  the  activity  and  data  models  of  the 
simulator.  They  are  given  as  a complete  functional  specification 
of  the  software.  None  of  the  box  titles  or  arrow  labels  are  bind- 
ing, however,  and  in  the  design  refinement  of  the  next  chapter  some 
names  and  labels  are  changed  to  better  meet  the  software  engineer- 
ing goal  of  understandability. 


V.  Deslfin  Refinement 


Introduction 

In  the  previous  chapter,  a top-down  design  strategy  is  used 
to  create  activity  and  data  models  which  Identify  a basic  design 
structure.  To  better  prepare  the  design  for  easy  Implementation, 
a structure  Is  needed  v/hlch  reveals  the  relative  "goodness"  of  the 
design.  This  goodness  Is  measured  by  observing  the  following  at- 
tributes: (1)  coupling,  (2)  cohesion,  (3)  span  of  control,  and  (i^.) 
scope-of-ef fect/scope-of-control  (Ref  10:340).  If  two  modules  are 
totally  independent  of  each  other,  and  one  can  function  completely 
without  the  other,  then  they  are  loosely  coupled,  or  uncoupled. 
Loosely  coupled  modules  are  more  maintainable  than  tightly  coupled 
modules.  Low  cohesion  occurs  when  an  isolated  module  has  internal 
elements  that  are  loosely  related,  Cohesiveness  and  coupling  are 
interrelated.  The  greater  the  cohesiveness  of  individual  modules, 
the  lower  the  coupling  between  any  pair  of  modules  will  be  (Ref 
10; 144) • Excessive  span  of  control  is  bad  because  it  indicates 
too  much  decomposition  of  a module  into  subordinates.  This  is 
caused  by  a failure  to  identify  intermediate  levels  of  abstraction. 
Finally,  scope-of-ef fect/scope-of-control  should  be  examined  to 
get  a measure  of  how  well  the  system  has  adhered  to  the  subordinate 
structure  required  of  any  decision  process:  all  modules  that  are 
affected  by  a decision  (scope  of  effect)  should  be  subordinate  to 
(scope  of  control)  the  module  which  makes  the  decision  (Ref  10:240). 
To  recogniz.;  and  isolate  the  existence  of  these  effects,  and  then 
to  eliminate  them  with  a design  refinement,  a technique  is  omployod 
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which  is  based  on  a top-down,  structured  design  strategy  called 
"transform  analysis,"  This  strategy  should  lead  to  system  struc- 
tures which  are  fully  factored  and  ready  to  code  (Ref  10:25/f), 

Transform  analysis  produces  a "structure  chsirt"  which  reveals 
design  goodness  measures.  The  structure  chart  contains  modules 
arranged  top-down  and  left-right  which  represent  the  processing 
functions  of  the  system.  The  first  step  is  the  restatement  of  the 
problem  as  a data  flow  graph  or  "bubble  chart,"  The  basic  elements 
in  a bubble  chart  are  called  "transforms"  which  are  represented 
by  circles  labeled  with  short  descriptions  of  the  transformation. 
Interconnections  between  transforms  are  labeled  arrows  which  rep- 
resent "data  elements"  to  be  transformed.  Two  or  more  data  elements 
required  simultaneously  by  a transform  are  indicated  with  an  aster- 
isk ("*")  between  the  data  elements.  The  "ring-sum"  operator  ("®") 
is  used  to  denote  exclusive-OR  relationships  between  data  elements. 
Bubbles  and  arrows  are  drawn  which  represent  input  branches  and 
output  branches.  These  bran.ches  are  connected  by  bubbles  that  are 
the  "central"  transforms  of  the  system.  The  second  step  is  to  iden- 
tify "afferent"  and  "efferent"  data  elements.  An  afferent  data 
element  is  an  input  to  a central  transform  and  an  efferent  data 
element  is  an  output  from  a central  transform.  The  third  step  is 
top-level  factoring.  A "main"  module  is  specified  and  it  is  decom- 
posed into  afferent,  efferent  and  central  modules.  The  fourth  step 
is  the  decomposition  of  the  afferent,  efferent  and  central  modules. 
The  top-level  modules  and  their  subordinates  form  the  "first  cut 
structure  chart,"  Finally,  the  first  cut  structure  chart  is  exam- 
ined for  goodness  and  revisions  are  made  to  produce  the  fizial  struc- 
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ture  chart  (Ref  10:  Chap.  10). 

After  the  preliminary  design  is  complete  the  first  cut  struc- 
ture chart  is  dravm  from  the  activity  model,  bypassing  the  creation 
of  a bubble  chart.  This  decision  is  based  on  the  conceptual  resem- 
blance of  the  activity  model  to  the  bubble  chart  in  that  both  tie 
activities  together  with  data  elements.  Reference  3 explains  a 
method  of  design  which  creates  an  "intermediate"  bubble  chart  from 
the  first  cut  structure  chart.  Iterations  of  bubble-to-structure- 
chart  and  structure-to-bubble-chart  transformations  are  made  to 
further  refine  the  design.  This  iterative  process  advocates  start- 
ing with  a structu  chart  and  then  creating  the  bubble  chart  for 
the  transform  analysis. 

In  the  remaining  sections  of  this  chapter,  i;he  first  cut  struc- 
ture chart  is  constructed  as  a direct  translation  (input  for  input, 
output  for  output)  from  the  activity  model  in  Chapter  III.  The 
afferent  and  efferent  data  branches  are  identified  to  aid  in  con- 
struction of  the  intermediate  bubble  chart.  Finally,  a "refined" 
structure  chart  is  constructed  and  examined  to  determine  the  rel- 
ative goodness  of  the  design. 

First  Cut  Structure  Chart 

Figures  30a,  30b,  30c  and  30d  illustrate  a direct  translatJon 
of  the  activity  model  of  Chapter  III  to  a structure  chart.  Deci- 
sions and  loops  are  not  identified  at  this  time;  they  are  included 
in  the  refined  structure  cha'  4:.  derived  later.  The  number  to  the 
left  of  each  arrow  identifies  the  input  and  output  parameters  listed 
in  Table  I,  Controls  are  not  indicated  in  this  list  because  they 
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Create 


Figure  30d.  Create  Output  Messages 

are  not  considered  when  creating  a bubble  chart  for  transform  anal- 
ysis. However,  a control  element  in  an  activity  module  may  be  used 
as  an  input  element  in  a bubble  chart. 

Intermediate  Bubble  Cliart  ( Data  Flow  Granh) 

The  bubble  chant  transforn.s  "conceptual  Inputs"  into  "concep- 
tual outputs,"  which  implies  that  the  detail  in  the  structure  chart 
may  be  higher  than  in  the  bubble  chart  (Ref  3:  Chap.  2,  p.  25'> . 

A scan  of  the  parameters  in  Table  I shows  some  repeated  input  and 
output  names  that  may  have  to  be  altered  to  clarify  the  data  flow. 

If  there  are  any  errors  in  the  structure  chart,  they  should  be  cor- 
rected while  drawing  the  bubble  chart.  Looking  at  the  top  level 
in  Figure  30a,  the  afferent  data  branch  is  recognized  as  that  branch 
which  consists  of  the  subordinates  of  the  Process  Input  Word  module. 
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Table  I 

First  Cut  Structure  Chart  Parameters 


Input  Output 


1 Input  Word  Status  Mod,  Invalid  Cmd,  Valid  Cmd 

2 Current  Status 

3 CV  Words 

if  CV  V/ords  Output  Messages 

5 Input  Word  Status  Mod,  S/C  Cmd 

6 Input  Word  Formatted  Cmd 

7 Formatted  Cmd  Format  Error 

8 Formatted  Cmd  Invalid  Cmd,  Specific  Cmd 

9 Formatted  Cmd  Invalid  Cmd,  Valid  Cmd 

10  Update  Request 

1 1 Current  Status 

12  Specific  Format  Errors 

13  Specific  Sequence  Errors 

14  CV  Words 

15  CV  Words  Command  Verification  Message 

16  Status  Mod  Status  Update  Message 

17  Output  Messages 

18  User  Cmd  Status  Mod  Request 

19  S/C  Uplink  Cmd  S/C  Cmd 

20  Status  Hod 

21  Input  Word  S/C  Data 

22  Input  Word  S/C  Address 

23  Formatted  Cmd 

2if  Formatted  Cmd  Wordlength  Error 

25  Formatted  Cmd  Parity  Error 

26  Format  Error 

27  Erroneous  Cmd,  Error-Free  Cmd 

28  Formatted  Cmd  Command  Words 

29  Formatted  Cmd  Address  Error 

30  Formatted  Cmd  Sequence  Error 

31  Formatted  Cmd  Command  words 

32  User  Status  Change  Request 

33  Commanded  Status  Change  Request 

34  Update  Request 

35  Telemetry  Changes 

36  Status  Message  Changes 

37  Current  Status 

38  Parity  Error 

39  Wordlength  Error 

40  Specific  Format  Errors 

41  Memory  Load  Errors 

42  Secure  Command  Error 

43  — Command  Sequence  Errors 

44  Specific  Sequence  Errors 

45  Sequence  Error  Code 

46  Format  Error  Code 

47  Specific  Command  Code 

48  CV  Words 
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Jn  Figure  30d,  the  efferent  data  branch  consistB  of  the  subordinateu 
of  Create  Output  MesBagee,  ThiB  leaveB  Update  Vehicle  StatuB  and 
Create  CV  WordB  as  the  central  traneformB.  The  afferent  data  branch, 
which  Identifies  the  major  Input  data  flow  to  the  central  transformB, 
is  the  first  to  be  drawn  In  the  bubble  chart.  Following  that  branch 
down  to  Its  lowest  level,  the  first  Input  parameter  seen  Is  a "User 
Cmd."  It  Is  the  Input  to  Read  Status  Mod  V/ord  and  the  output  Is 
a "Status  Mod  Request."  This  Identifies  the  Input,  first  bubble, 
and  output  In  this  portion  of  the  bubble  chart.  To  locate  the  next 
bubble,  the  module  which  uses  "Status  Mod  Request"  as  an  Input  must 
be  found.  It  cannot  be  located  as  an  Input  In  Table  I,  but  It  may 
be  a control  element  In  the  activity  model.  Looking  back  to  Fig- 
ure 6,  which  Is  the  activity  node  that  contains  the  modules  of  In- 
terest, "Status  Mod  Request"  Is  a control  on  Perform  Status  Mod. 
"Status  Mod  Request"  Is  used  as  an  Input  to  the  next  bubble,  which 
Is  Perform  Status  Mod.  The  output  of  Perform  Status  Mod  Is  shovm 
in  the  activity  model  as  "Status  Mod."  Looking  In  Table  I "Status 
Mod"  Is  found  as  an  Input  to  Produce  Status  Change  I Istlng  which 
Is  In  th(!  efferent  branch.  The  activity  model  Is  examined  to  see 
If  "Status  Mod"  Is  used  for  control  In  any  Intermediate  activities 
and  It  Is  found  as  a control  Input  to  Update  Vehicle  Status  which 
Is  a central  transform.  Continuing  this  process,  the  bubble  chart 
In  Figure  31  1b  constructed.  The  completed  bubble  chart  Is  now 
reviewed  to  ensure  that  It  accurately  represents  the  processing 
illustrated  in  the  structure  chart  (Ref  3:  Chap.  2,  p.  28),  then 
the  refined  structure  chart  is  drawn  and  analyzed. 


Afferent  Data  Elenent 


Figure  31.  Intermediate  Bubble  Chart 


Refined  Struc ture  Chart 


Input  and  output  arrows  have  been  included  on  the  structure 
charts  in  Figures  32,  33,  34,  35,  36  and  37  to  enhance  the  clarity 
of  each  diagram.  A dot  at  the  end  of  the  arrow  indicates  a control 
element,  while  a circle  indicates  a piece  of  data  being  passed  be- 
tween modules.  The  charts  are  presented  in  a top-down,  left-right 
structure  starting  with  the  "main"  or  top-1  ^1  modulo  and  each 
of  its  subordinates.  Then  each  of  those  subordinates  is  decomposed 
and  analyzed  as  independent  sections  of  each  branch.  Accompanying 
each  chart  is  a parameter  list  which  adds  to  the  understandability . 
The  main  module  in  Figure  32  identifies  the  afferent  data  branches 
by  showing  only  inputs  to  the  main  modul  . The  efferent  branch 
has  only  outputs  from  the  main  module  and  the  central  transforms 
have  data  going  in  both  directions.  The  following  is  a brief  de- 
scription of  each  module  and  the  interconnections  with  its  subor- 
dinate modules.  At  each  level  any  decisions  or  loops  that  may  oc- 
cur will  be  explained  and  justified  if  necessary. 

SI^^TLATE  SPACCRFT.  This  is  the  main,  or  executive  module. 

Its  function  is  to  control  and  coordinate  the  afferent,  transform, 
and  efferent  modules  dealing  with  the  highest  level  data  of  the 
system.  All  of  these  subordinate  modules  are  in  the  executive's 
scope  of  control.  When  the  executive  is  invoked  it  will  load  the 
top-level  afferent  modules  and  output  a "ready"  message  response 
jrhen  that  loading  is  complete.  This  is  a signal  to  the  user  that 
the  simulator  is  ready  to  accept  user  command  or  spacecraft  command 
Inputs. 

QET  STATMQD.  Loose  coupling  exists  between  this  modulo  (Fig- 
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Figure  ^>3.  bTATHOD  Module  and  Subordinates 


ure  33)  and  the  executive.  This  allows  the  exclusion  of  the  module 
from  the  simulator  without  affecting  the  performance  of  the  rest 
of  the  system.  The  module  is  designed  to  perform  functions  such 
as  adding  entries  to  existing  status  and  telemetry  tables,  delet- 
ing those  entries,  or  changing  them.  These  are  functions  that  could 


be  performed  externally  if  the  operating  system  had  an  editing  rou- 
tlneo  If  the  option  to  use  this  module  as  part  of  the  simulator 
is  taken,  a means  of  distinguishing  between  user  and  spacecraft 
commands  should  be  devised.  One  way  to  do  this  is  to  prefix  each 
user  command  with  some  identifying  character. 

Upon  receipt  of  a "User  Command''  from  INPUT  DSERCMD,  GENERATE 
STATMODREO  controls  its  acceptance  and  the  subsequent  "set-up"  nec- 
essary to  pass  the  request  to  the  PERFORM  STATKOD  module  where  the 
request  is  translated  and  the  proper  modification  is  performed. 

The  "Status  Modification"  is  then  used  as  constraint  data  for  other 
processes.  INPUT  USERCMD  and  SETUP  STATMO.DWRD  may  be  "dummy"  modules 
whose  implementation  is  so  trivial  that  they  may  be  compressed  into 
their  superordinate  (Ref  10:344) • Dummy  modules  are  a common  prod- 
uct of  a top-down  design.  Although  dummy  modules  rarely  degrade 
system  performance,  they  should  be  reconsidered  before  implementa- 
tion. 

Spacecraft  Command  Afferent  Branch.  This  afferent  data  branch 
performs  the  major  task  of  the  simulator:  spacecraft  command  proc- 
essing. To  enhance  its  description,  the  entire  branch  is  drawn  in 
Figure  34*  Tlie  left-right  construct  convention  has  been  violated 
in  some  places  to  avoid  crossing  arrows.  The  parameter  list  in 
Table  II  should  be  referenced  while  reading  the  following  descrip- 
tion. 

The  diamonds  in  the  diagram  represent  decision  processes. 

The  presence  of  a decision  requires  examination  of  the  scope-of- 
effect/scope-of-control  attributes  discussed  earlier.  GET  VAI.CMD 
hsis  PERFORM  CMDVALCKS  and  ACCEPT  SPECCMD  in  its  scope  of  control. 
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A "Specific  Command"  must  be  accepted  by  GET  VALCMD  and  the  command 
validity  checks  (sequence  checks,  timing  checks)  must  be  performed 
by  PERFORI-I  CMDVALCKS  before  a "Sequence  Error"  can  be  detected. 
Since  PERFORM  CMDVALCKS  determines  the  existence  of  a "Sequence 
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Table  II 

Spacecraft  Command  Afferent  Branch  Parameters 


Input 

Output 

10 

1 1 

Sequence  Error 

Sequence  Error,  Specific  Command 
Specific  Command,  Command  Type 

12 

Specific  Command 

Sequence  Error 

22 

Good  Command 

23 

Good  Command 

Specific  Command,  Command  Type 

24 

Erroneous  Command 

Format  Error  Command 

25 

Erroneous  Command 

47 

Formatted  Uplink  Words 

48 

Formatted  Uplink  Words 

Good  Command 

49 

Erroneous  Command 

50 

Uplink  Command 

51 

Uplink  Command 

Formatted  Uplink  Words 

Error,"  it  is  the  only  module  within  the  scope  of  effect  of  GET 


VAIiCHD.  The  next  decision  process  takes  place  in  the  GET  aOOBCMD 
module.  Its  scope  of  control  includes  GET  FMTDPTODS  and  PERFORM 
QENVALCKS.  PERFORM  GENVALCKS  is  in  the  scope  of  effect  of  GET 
GOODCMD.  No  other  module  is  effected  by  the  process.  Control 
coupling  exists  between  GET  VAICMD  and  GET  SEQERRCMD  because  a se- 
quence error,  if  one  exists,  is  passed  throvgh  GET  VAI.CMD  to  GET 
SEQERRCMD  before  the  "Sequence  Error  Command"  can  be  transmitted 
up  to  the  executive.  This  coupling  could  reduce  maintainability 
and  should  be  examined  before  implementation  to  see  if  it  can  be 
eliminated.  This  entire  afferent  branch  is  the  most  complex  of 
the  whole  simulator.  However,  the  loose  coupling  between  modules 
resulting  from  the  design  methodology  yields  a structure  that  is 
relatively  easy  to  implement.  The  relationship  between  coupling 
and  cohesion  implies  that  the  loose  coupling  produces  high  cohesion 
In  each  module  which  is  a desired  attribute.  A brief  explanation 
of  the  spacecraft  command  processing  follows. 
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An  "Uplink  Command"  is  received  by  GET  UPV/RDS  and  the  FORMAT 
UPWRDS  module  does  necessary  formatting  of  the  uplink  command  words, 
GET  GOODCMD  accepts  these  "Formatted  Uplink  Words"  and  passes  them 
to  the  PERFORM  GENVALCKS  module  where  they  are  checked  for  parity 
and  wordlength.  If  either  one  of  those  errors  exists  the  "Errone- 
ous Command"  is  received  by  the  GET  FMTERRCMD  module  and  passed 
to  DETERMINE  TYPECMD  where  the  type  of  command  is  determined.  The 
command  with  the  format  error  is  then  passed  to  the  executive  for 
further  processing.  If,  after  the  general  validity  checks  are  per- 
formed, no  errors  are  found,  the  "Good  Command"  is  passed  to  the 
control  of  the  GET  VAICMD  module  and  held  for  sequence  checking. 

The  sequence  checks  are  performed  after  the  specific  command  type 
is  determined.  If  a sequencing  error  occurs,  control  is  passed  to 
the  GET  SEQERRCMD  module  where  the  "Erroneous  Command"  is  passed 
upward  to  the  executive.  Erroneous  commcinds  are  used  to  generate 
the  appropriate  command  verification  message  and  output  message 
which  gives  the  user  a description  of  the  errors,  but  they  do  not 
affect  the  performance  of  any  other  modules, 

MODIFY  VEHSTAT,  The  scope-of-ef fect/scope-of-control  is  more 
obvious  in  this  module  than  it  was  in  the  afferent  branch.  Figure 
35  and  Table  III  should  be  referred  to  while  reading  the  explana- 
tion of  the  functions  performed. 

If  READ  CMDDATA  receives  a "Valid  Command,"  the  "Command  Data" 
portion  of  the  command  is  read  and  a "Status  Modification  Request" 
is  generated.  The  "Status  Modification  Request"  is  then  passed  as 
control  data  to  PERFORM  MODIFICATION,  The  loop  indicates  the  pos- 
ibility  of  multiple  telemetry  changes  and  status  message  changes 
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Figure  35.  VEHSTAT  Module  and  Subordinates 


Table  III 

VEHSTAT  Parameters 


Input 

Output 

13 

14 

Valid  Command » Command  Type 
Status  Modification  Request, 

Status  Modification  Request 
Current  Status 

26 

27 

28 

Change  Request 

Valid  Command 

Command  Data 

Status  Modification 

Command  Data 

Status  Modification  Request 
Change  Request 

29 

30 

31 

Change  Request 

Status  Modification  Request 
Modified  Status 

fiodified  Status 

Modified  Status 

Current  Status 

required  by  one  command*  The  status  modifications  generated  by 
a valid  spacecraft  command  are  assembled  and  the  "Current  Status" 
is  relayed  to  the  PRODUCE  OUTMESS  module  and  a explanatory  message 
is  produced*  A modification  request  could  also  result  from  a "User 
Command,"  in  which  case  the  "Status  Modification"  is  used  to  gener- 
ate a "Change  Request*"  The  portion  of  the  module  which  consists 
of  GENERATE  CHGREQ  can  bo  omitted  if  an  edit  routine  is  used  for 
"User  Commemd"  processing* 

PROCESS  CVWORDS*  Command  verification  (CV)  codes  exist  for 
most  commands*  The  subordinates  of  PROCESS  CVWORDS  creates  appro- 
priate "CV  Words"  that  are  used  to  produce  output  messages  (see 
Figure  36  and  Table  IV) • The  transform  analysis  has  revealed  a 
possible  weakness  in  the  design  of  this  portion  of  the  simulator* 
This  weakness  is  indicated  by  the  "pancfike"  structure  that  has 
occurred.  "Pancaking"  is  a common  phenomenon  that  results  from 
a top-down  design.  It  usually  indicates  a lack  of  sufficient  de- 
composition. The  FIND  TYPSEQERR  module  should  be  decomposed  fur- 
ther because  it  requires  intermediate  processing  that  is  not  shown* 
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Table  IV 

CVWORDS  Parameters 


Input 

Output 

15 

Format  Error  Command 

Format  Errors 

16 

Sequence  Error  Command 

Sequence  Errors 

17 

Valid  Command,  Format 

Errors.  Sequence  Errors 

CV  Words 

32 

Parity  Error  Command 

Parity  Error 

33 

Wordlength  Error  Command 

Wordlen|3;th  Error 

34 

Parity  Error,  Wordlength 

Frror 

Format  Error  List 

35 

Memory  Load  'Words 

Memory  Load  Error 

36 

Secure  Command 

Secure  Command  Error 

37 

Timed  Commsind 

Sequence  Error 

38 

Memory  I.oad  Error,  Secure 
Command  Error.  Sequence  Error 

Sequence  Error  List 

39 

Sequence  Errors 

Sequence  Error  Code 

40 

Format  Errors 

Format  Error  Code 

41 

Valid  Command 

Specific  Command  Code 

42 

CV  Codes 

CV  Words 

A command  with  format  errors  (parity,  wordlongth)  is  processed 
by  FIND  TYPFMTERR  to  determine  the  types  of  errors  it  contains. 

The  iterative  decision  suggests  a sequential  check  of  both  parity 
and  wordlength.  The  "Format  Error  List"  created  is  accessed  by 
DETERMINE  VEHMESCODES  and  the  specific  "Format  Errors"  are  used 
to  determine  the  proper  CV  codes  needed  to  produce  a CV  message. 

The  FIND  TYPESQERR  module  is  required  to  process  a variety  of  er- 
rors that  are  classified  as  "Sequence  Errors."  These  include  (1) 
"Memory  Load  Errors"  resulting  from  Improper  memory  word  lengths, 
(2)  "Secure  Command  Errors"  generated  when  a "Secure  Command"  is 
not  preceded  by  the  proper  "prologue"  command  (Ref  1),  and  a (3) 
"Sequence  Error"  that  results  from  improper  timing  between  the  pro- 
logue command  and  the  executed  spacecraft  "Secure  Command."  These 
errors  must  all  be  recogniv.ed  and  assembled  in  the  same  manner  as 
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Parameterc 


Input 

Output 

18 

Valid  Command,  Current 

Status,  Status  Modification 

19 

CV  Words 

— 

43 

Valid  Command,  Current 

Status.  Statue  Modification 

Status  Listing 

44 

Modification  Message 

— 

CV  Words 

CV  Message 

46 

CV  Message 

— 

Figure  37*  OUTMBSS  Module  and  Subordinates 

parity  and  wordlength  errors,  DETERMINE  VEHMESCODES  accepts  the 
errors  that  have  been  found  during  the  command  procestlng  and  lo- 
cates the  proper  command  verification  codes  that  adequately  describe 
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the  error 


PRODUCE  OUTMESS,  Thin  in  the  efferent,  or  output  branch  of 
the  simulator.  It  accunulaten  all  errors  and  status  modifications 
generated  during  command  processing  and  provides  a meaningful  out- 
put message.  The  module  and  its  associated  parameter  list  are  shown 
in  Figure  37 • 

The  "Valid  Command"  and  "Current  Status"  information  £U*e  used 
to  produce  a current  "Statue  Listing"  which  is  an  explanatory  state- 
ment of  changes  made  and  commands  executed.  "CV  Words"  are  also 
listed  with  descriptions  c f their  meaning. 

Summary 

Three  previously  tried  design  techniques  are  combined  into 
one  design  methodology  in  this  chapter.  The  activity  model  created 
during  the  preliminary  design  is  converted  directly  to  a first  cut 
structure  chart  with  no  design  modifications.  An  intermediate  bub- 
le  chart  is  constructed  from  the  first  cut  structure  chart.  During 
construction  of  the  bubble  chart  a roevaluation  of  each  module  is 
made  with  emphasis  on  the  conceptual  representation  intended  by 
the  bubble  chart.  After  ensuring  the  bubble  chart  properly  illus- 
trates the  desired  system  data  flow,  a new  structure  chart  is  cre- 
ated which  represents  a design  refinement.  This  structure  chart 
ii)  then  analyzed  for  "goodness"  of  design  by  looking  for  deficien- 
cies in  coupling,  cohesion,  scope-of-ef fect/scope-of-control. 
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V.  PoslRn  Annlyslc 


Introduction 

Thin  chapter  is  a summjxry  of  the  Information  gained  through- 
out this  thesis  project.  The  value  of  the  design  is  discussed  and 
ST'ggestions  to  improv  the  design  are  given.  Deficiencies  noted 
during  phases  of  the  design  are  pointed  out,  and  recommended  rem- 
edies for  those  deficiencies  are  presented.  Since  the  software 
design  methodology  employed  in  this  project  is  relatively  new  and 
untried,  this  chapter  also  contains  observations  and  recommendations 
for  its  continued  usage. 

Summary 

The  first  problem  addressed  in  this  design  project  is  the  need 
for  a sound  analysis  procedure  that  aids  in  defining  requirements 
for  a design.  A study  of  SofTech's  Structured  Analysis  and  Design 
Technique  shows  that  their  methodology  yields  a top-down,  modular, 
hierarchic,  and  structured  design.  Those  desirable  design  charac- 
teristics facilitate  programming  for  implementation.  The  activity 
and  data  models  are  constructed  with  satisfactory  results.  Through- 
out the  consti'uction  of  the  activity  model  an  inability  to  define 
the  input,  output,  or  control  is  an  indication  of  a lack  of  under- 
standing of  the  particular  activity.  Consequently  the  system  is 
studied  further  to  a level  of  understanding  that  allows  progress 
to  continue.  The  same  is  true  when  constructing  the  data  model. 

The  data  model  is  useful  as  a continuity  check  between  blocks  in 
the  activity  model.  The  two  models  are  excellent  tools  that  make 


a comploto,  undoretandablo  roquiromonto  definition  pocniblo  and 
provide  a well  defined  preliminary  decign. 

Structure  chnrtc  are  used  an  efficient  noano  of  refining  the 
Bimulator  dordgn  to  prepare  it  for  the  programming  phano  of  devel- 
opment. The  structured  analyols  (activity  and  data  models)  loaves 
the  question  of  "goodness"  of  design  unanswered.  The  question  is 
answered  by  the  construction  of  structure  charts.  The  problem  is 
how  to  maliO  a smooth  transition  from  the  SAPT’  methodology  to  the 
Transform  Analysis  used  to  derive  the  structure  charts.  The  acti- 
vity model  is  redrawn  into  a structure  chart.  This  transition  yields 
a structure  chart  that  better  identifies  the  essential  olononts  in 
the  system.  Next,  an  "intermediate"  bubble  chart  is  drawn  based 
on  a structured  design  method  by  Hughes  Aircraft  (Ref  5)*  The  re- 
evaluation  of  intermodular  connections  at  each  stage  of  bubble  con- 
struction results  in  the  location  and  correction  of  poorly  defined 
connections.  Now  Transform  Analysis  (Ref  10:  Chap.  10)  can  bo  used 
to  derive  a more  refined  structure  chart.  Upon  completion  of  the 
refined  structure  chart,  a thorough  examination  of  each  modulo  re- 
eults  in  identification  of  some  firoas  that  need  further  vonalynis. 

The  combination  of  the  throe  design  mothodolgios,  structured 
analysis,  structured  design,  and  Hughes'  iteration  of  structured 
design  results  in  a simulator  design  that  meets  or  exceeds  the  or- 
iginal design  goals.  The  system  is  modular  and  understandable* 

The  loose  coupling  between  modules  enhances  the  modifiability  and 
maintainability  of  the  simulator.  The  well  defined  scope-of-of feet/ 
Bcope-of-control  within  a branch  of  the  system  maintains  the  f\mc- 
( tional  independence  desired,  even  in  the  moot  complex  branches. 
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After  incorporating  the  rocom.nondation6  givoi.  below,  the  structured 
design  can  be  given  to  a progranming  section  with  full  confidence 
that  the  system  requirements  will  be  met. 

Conclusions  and  Reconuncndatlons 

In  Chapter  IV,  the  first  cut  structure  chart  would  bo  easier 
to  understand  if  the  control  elements  were  included  in  the  parame- 
ter list.  It  is  recommended  that  all  inputs,  outputs,  and  controls 
be  Included  in  the  first  cut  structure  chart  as  a central  reference 
for  bubble  chart  construction. 

The  TYPSEQERR  modulo  shown  in  Figure  36  on  page  90  needs  fur- 
ther decomposition  to  better  define  its  function.  This  module  can 
bo  examined  independently  and  modified  ns  required  without  affect- 
ing the  other  subordinates  of  PROCESS  CVWORDS,  That  examination 
should  be  maiie  before  coding  is  attempted. 

To  be  consistent  with  a software  life-cycle,  each  module  in 
the  given  structure  charts  should  be  flow-cheirted  for  coding.  Be- 
fore this  is  attempted,  however,  the  structure  charts  should  be 
studied  by  the  coders  to  clarify  any  veiguo  portions  of  the  struc- 
ture. This  clarificaticn  should  be  made  by  reading  the  Design  Re- 
finement in  Chapter  IV.  If  further  clarification  is  needed,  another 
iteration  from  a new  bubble  chart  to  another  structure  chart  should 
be  performed. 

This  thesis  addresses  the  simulation  of  the  command  section 
of  the  Block  5D  satellite  with  successful  results.  It  is  recommended 
that  other  spacecraft  functions  be  smalyzed  using  the  methodology 
presented  in  this  design.  Each  main  function  can  be  designed  in- 
dependently and  added  to  this  design  at  a later  time. 
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